Device-to-device (D2D) communication (which may interchangeably referred to herein as proximity services (ProSe) or sidelink communication) is a well-known and widely used component of many existing wireless technologies, including ad hoc and cellular networks. Examples include Bluetooth and several variants of the IEEE 802.11 standards suite, such as WiFi Direct. These systems operate in unlicensed spectrum.
Recently, D2D communications as an underlay to cellular networks have been proposed as a means to take advantage of the proximity of communicating devices and at the same time to allow devices to operate in a controlled interference environment. Typically, it is suggested that such D2D communications share the same spectrum as the cellular system, for example by reserving some of the cellular uplink resources for D2D purposes. Another possibility is allocating dedicated spectrum for D2D purposes. Allocating dedicated spectrum for D2D purposes is a less likely alternative, however, as spectrum is a scarce resource and (dynamic) sharing between the D2D services and cellular services is more flexible and provides higher spectrum efficiency.
Devices that want to communicate, or even just discover each other, typically need to transmit various forms of control signaling. One example of such control signaling is the so-called (discovery) beacon signal, which at least carries some form of identity and is transmitted by a device that wants to be discoverable by other devices. Other devices can scan for the beacon signal and, once they have detected the beacon, can take appropriate action—such as trying to initiate a connection setup with the device transmitting the beacon. For certain communication modes (such as connectionless communication, which is typically employed for group-cast and broadcast transmission), the beacon signal might carry a scheduling assignment indicating the associated data transmission to potential receivers. Connectionless communication is typically a unidirectional communication mode that does not require acknowledged connection setup.
The ProSe Study Item 3GPP TR 36.843 v12.0.1 recommends supporting D2D operation for out-of-network coverage user equipment (UEs). In such a case, different synchronization options are possible. As one example, UEs may synchronize to a global reference (e.g., a GPS), which is in general different from the synchronization reference of deployed networks. As another example, UEs may operate in a fully asynchronous fashion (i.e., no synchronization reference, at least for discovery). Yet another option is that clusters of UEs may synchronize to a specific UE (in the following referred to as Cluster Head (CH)), which provides local synchronization to its neighbor UEs. Different clusters are not necessarily synchronized. If out-of-network coverage synchronization is based on sync signals transmitted by CHs, it is necessary that UEs synchronize to the suitable synchronization reference (i.e., CH). A number of procedures may be considered, with some similarities to cell search in cellular networks, in which idle UEs search for sync signals from different cells and synchronize to, for example, the cell with the best signal strength. Similarly, ProSe enabled out of network coverage UEs might synchronize to the strongest CH in proximity.
UEs may discover unsynchronized beacons on a given carrier (or sub-band) by searching for discovery beacons in time over their configured/predefined resources. This can be done, for example, by time domain correlation of the received signal with the beacon's waveforms, similar to the way UEs search for cells using primary/secondary synchronization signal (PSS/SSS). UEs alternate wake-up and sleep cycles for reducing power consumption (i.e., discontinuous reception (DRX)). During sleep periods, only the memory and clocks are active, but the UE is unable to receive any signal. During wake-up time, the receiver is on. It is essential that the wake-up time periods are as narrow as possible compared to the sleep time in order to save battery.
Looking at coverage in a bit more detail, there are basically three different cases. In the first case, all communicating UEs are within network coverage. In this case, the network also controls the D2D communication, such as synchronization, scheduling, etc. In the next case, all communicating UEs are outside network coverage. In this context, out-of-coverage may mean that the UE is unable to successfully communicate with any cellular network which may act as support to ProSe operations, but other definitions of out-of-coverage are possible. In the out-of-coverage case, the UEs will mostly rely on pre-configured information (i.e., information that was obtained when the UE was connected to a network). With the use of beacons and scheduling requests/grants, other information is exchanged, such as synchronization and resources to use. A third case, partial coverage, results when some of the communicating UEs are within network coverage and some are not. The difficult case occurs when the receiving UE is within coverage (including either case that the transmitting UE is in or out-of-coverage). In such a case, it may be that the receiving UE communicated on the UL with the eNB; communication which will prevent the UE from receiving the broadcast from the UE out of coverage.
To better coordinate interference, the scheduling of D2D transmissions can be coordinated by the eNB when UEs are in network coverage. In order for the eNB to better assign a correct amount of transmission resources, the UEs send ProSe buffer status reports (BSRs) to the eNB. A similar mechanism exists for coordination of uplink transmissions. The ProSe BSR contains information about the amount of data currently available for transmission on the sidelink interface. As the UE may have some data available for transmission on the sidelink interface as well as some data available for transmission on the uplink interface, there may be occurrences when the UE transmits both a ProSe BSR and an ordinary BSR. According to existing solutions, a UE performs buffer status reporting serially (i.e., the UE performs buffer status reporting for uplink and then sidelink, or vice versa, with only one buffer status report per MAC PDU). Such a solution may have certain deficiencies. For example, performing buffer status reporting serially delays network awareness of UE status, and may cause a service delay as a result of requesting/allocating resources for the UE's uplink data followed by the sidelink data.